原帖 ｜ 🌶 ｜ 2026-01-09 18:58 ｜ 👍0 ｜ 阅读约1
嵌入式研究视角之编译视角：
首先，我们需要明确一个事情，Linux大部分由C语言构成，那么要研究Linux，C语言的重要性不言而喻。那么平时我们喜欢看些书籍补足理论，比如《》，这本书有提到嵌入式研究的角度，内存视角，编译器视角，架构视角，这里我们主要提到的是编译器视角。
翻翻书可以看到C语言编译的基本过程是：.c (源文件) 经预处理生成 .i (预处理文件)，再经编译生成 .s (汇编文件)，随后经汇编生成 .o (目标文件)，最后经链接整合库文件生成 可执行程序 (无后缀或 .exe)
我们调试过程中常用的一个思路就是假说演绎法，这个方法的意思就是修改特定逻辑，然后烧录测试查看效果是否符合预期来验证思路，但是因为我们实际项目中往往版本源码比如说Andrio6为了方便是兼容多个机型的，当我们运行编译脚本build.sh，脚本逻辑才会根据传入机型参数进行对应设备树和内核配置的选择，那么我们来梳理这个逻辑，我们要验证逻辑实现是否正确，首先要排除一个问题就是我们的代码确实被编译进了内核，对于这个庞大的源码，查看Makefile进行定位显然相当麻烦，因为SDK父文件夹往往只是调用各个子文件夹下的Makefile，我们要找到这个调用逻辑还需要对应机型参数去查看子文件夹Makefile，那么有简单的思路吗？当然有的，要是我们对C语言的编译流程比较熟悉，我们其实就可以通过一个简单的编译现象来进行这个问题的排查，.c->.o这个是编译进内核的必经之路，那么我们自然的想到通过.o文件的时间戳来查看是否是最近生成，因为.c生成的.o往往是同名，并且时间戳是绝对的，这两个利好就会让我们的排查非常方便，当我们执行编译指令，只需要使用ls -l指令查看.c同名.o文件是否生成，生成时间戳就可以判断Makefile是否执行编译，内核中是否包含我们修改的编译逻辑，从而再继续验证我们的代码逻辑是否正确，反过来也可以通过这个.o文件来定位我们具体的Makefile，打通整个编译链路，掌握编译视角，让我们对linux这个庞大的C语言集合有一个比较明晰的认知，使得我们可以针对性的需要改动哪个文件就可以验证哪个链路，避免浪费时间。
相关笔记
- 📁 返回本主题 MOC
- Linux BSP问题闭环流程
- Linux 调试手段，涵盖 printk 使用、动态打印、trace
- 从MCU转Linux BSP开发
- 设备树反编译调试
- 很多人不知道 Android 和 Linux（如 Ubuntu） 的关系
- 老师，构造的作用和意义是什么？